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Claims Text - CLTX (7) : 

2 . The data storage hierarchy of claim 1 wherein the 
first file system is 

shared filed system which dynamically allocates storage space 
among a plurality 

of first file system users as their files are stored therein 
and the second 

file system is a preallocated file system which allocates 
contiguous storage 

space to each of a plurality of second file system users 
prior to their files 
being stored therein. 

Claims Text - CLTX (14) : 

4 . The data storage hierarchy of claim 3 wherein the 
first file system is a 

shared file system which dynamically allocates storage space 
among a plurality 

of first file system users as their files are stored therein 
and the second 

file system is a preallocated file system which allocates 
contiguous storage 

space to each of a plurality of second file system users 
prior to their files 
being stored therein. 



11/13/2003, EAST version: 1.4.1 



United States Patent im 

Tevis et aL 



US0O5317728A 

[ii] Patent Number: 5,317,728 
[45] Date of Patent May 31, 1994 



[54] STORAG E MANAGEMENT OF A FIRST FILE 
SYSTEM USING A SECOND FILE SYSTEM 
CONTAINING SURROGATE FILES AND 
CATALOG MANAGEMENT INFORMATION 



P5) 

[73] Assignee 



Inventors: Gregory J. Teris; EUen J. Waido, 
both of Tucson, Ariz. 



PI] 
P2] 

(51] 
[52] 

[58] 
[56] 



International Business Nlaebfnes 
Corporation, Armonk, N.Y. 

AppLNo,: 578,386 

Filed: SerJ.7,1990 „. 

Int. CI' ; : G06F 15/40 

us. a. 



395/600; 364/DIG. 1; 

364/22X81; 364/282.1; 364/281.1 

Field of Search 364/200; 395/725, 275, 

395/425, 600 

References Cited 

U.S. PATENT DOCUMENTS 



4,104,718 
4,499,539 
4^74346 
4,638,424 
4,638,425 
4,771,375 
4,876,662 
4,882,674 
4,974,156 
4,987,533 
5,001,628 
5^)18,060 
5,089,952 
5,121,483 



8/1978 
2/1985 
3/1986 
1/1987 
1/1987 
9/1988 
10/1989 
11/1989 
11/1990 
1/1991 
3/1991 
5/1991 
2/1992 
6/1992 



PocbJan et aL , 
Vosacek . 
Hartung 
Begiin ct aL . 
Hartung \ 
Beglin et aL , 
Pence . 



Quint et aL 
Harding etaL . 
Clark etaL 
Johnson et aL , 
GdbetaL 



etaL . 



395/600 
. 364/200 
395/425 
364/200 
364/200 
364/200 
364/900 
395/700 
. 395/425 
395/600 
. 395/600 
395/600 
.395/725 
. 395/275 



5,175,852 12/1992 Johnson et aL - 

5,193,171 3/1993 Shinmnra et aL 

5^02,971 4/1993 Henson etaL » 

5,239,647 8/1993 AnglinetaL _ 



395/600 
395/425 
395/425 
395/600 



Primary Examiner — Thomas C Lee 
Assistant Examiner^-Vf &ync Amsbury 
Attorney, Agent, or Firm— M. W. Schecter 



[571 



ABSTRACT 



A first file system to assist in the storage management of 
a second file system not able to store its own manage- 
ment classes and management attributes. A repository 
file space in the first file system is used to accomplish 
the storage of some or all of the management classes or 
attributes for the files of the second file system. For 
each file in the second file system an empty file is cre- 
ated in the repository file space of the first file system. 
The creation of an empty file in the repository file space 
causes a management class to be selected for the file and 
stored in the catalog of the first file system as would be 
done for any file in the first file system. A naming con- 
vention is used to link each file in the repository file 
space with its associated file in the second file system. 
The additional files in the first file system are left empty 
as no other information need be stored for storage man- 
agement purposes. The management attributes of the 
files are then compared to the management criteria 
represented by the management classes stored in the 
catal og of the first file system and the files are managed 
accordingly. 

5 Claims, 3 Drawing Sheets 
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lection of data in a prescribed arrangement and de- 
S TORAG E MANAGEMENT OF A FIR ST PIL E scribed by control information to which the system has 
SYSTEM USING A SECOND FILE SYSTEM access. An object is a variably sized byte stream withno 

CONTAINING SURROGATE FILES AND record or other internal boundary orientation. For con- 

CATALOG MANAGEMENT INFORMATION 5 venience, the term "file" is used hereinafter to refer 

BA^nntrvm geiierically to data sets, files, objects or any such data 

BACKGROUND OF THE INVENTION entities Data is moved and copied between different 

1. Field of the Invention levels of the hierarchy as files (or some larger unit of 
The present invention relates to storage management data), as required, to balance performance, storage and 

across file systems. More particularly, the invention 10 cost Such data transfers and related actions to manipu- 
relates to storage management of both die mtnwtkir and late a data storage hierarchy (such as the deletion of 
shared file systems in a virtual machine operating sys- data which is no longer being used from the hierarchy) 
tern environment in which at least some of the manage- to achieve this balancing is known as "storage manage** 
ment classes for the irrinirtisk file system files are stored merit". 

in the catalog in the shared file system. 15 Storage management includes several subcompo- 

2. Discussion of the Related Art nents, such as performance management, reliability 
Modern data processing systems include a host pro- management, capacity management, space management 

cesser having one or more central processing units, a and availability mam^m Each of these may in- 
memory facility, an input/output system, and an inter- volve the transfer of data between levels of the hierar- 
connccoon system (Le. a bus). The processor manipu- 20 chy. Space management is the movement of data be- 
ktesdata stored m , thememory accordmg tc^Btruc- tween different levels of the hierarchy so as to store 
^P ro ?**V° thercforC * data only in the most appropriate level of the peripheral 

S££X^ borage hierarchy. Fo%Sk relatively acZ data 

Se^S^^ * e «* «Mvely ^SvTdTlould be 

We. Inc cost and performance of computer me mor y is i s_ ... , J . , . * » 

♦k™« *~ *u*T ■ i ~™i 13 stored m a relatively lower performme level of the 

thus critical to the commercial success of a computer *• - A , ^ J . . *^ tr^ & * . . 

system F hierarchy. As data ages, it is generally referenced less 

As computers manipulate ever increasing amounts of ^ vc > and should thus be moved to 

data they require larger quantities of dataaorage capac- 30 lower lcvds ° fthc storage hierarchy. The move- 
ity. Computer memory is available in several forms. ment of data from one level of a data storage hierarchy 
Generally, the faster data can be written to or read from to aDOther B rcferrcd to 88 "migration-, and may in- 
a particular form of memory, the more expensive it is. elude data compaction to save storage space. 
Microchips are fast, but expensive, and are typically Availability management is the backup of data within 
used as the primary or main memory in/to the host 35 a data storage hierarchy to improve the likelihood of its 
processor. Other available forms of memory are used as **inE available if and when h is needed by the host 
auxiliary or peripheral memory, and include numerous processor. The original or primary copy of the data is 
peripheral storage devices. For example, magneto di- 1101 deleted; an additional or secondary copy is gener- 
rect access storage devices (DASD), magnetic tape ated and transferred to another portion of the data stor- 
storage devices, and optical recording devices are all 40 a £ e hierarchy. The secondary copy is typically stored 
peripheral storage devices. These devices have a 00 a different peripheral storage device from the pri- 
greater storage capacity and lower cost than main mem- mary copy to ensure the availability of the data. If the 
ory, but do not provide the same per f o rma nce. For primary copy of the data becomes unavailable, such as 
example, the time required to properly position a tape Dv device failure, the secondary copy of the data may 
or disk beneath the read/write ™*rhn™m of a drive 45 still be referenced. The secondary copy of the data need 
cannot compare with the rapid, purely electronic data not be stored in a different level of the data storage 
transfer rate of main memory i It is, however, inefficient hierarchy, but such may be desirable as the secondary 
to store all of the data in a system in a single type of copy is not likely to be as active as the primary copy, 
memory device. Simply storing all data in main memory Data backup may occur unconditionally or incremen- 
is too costly and simply storing all data in a peripheral 50 tally. Unconditional backup generates a copy of any 
storage device significantly reduces performance. A specified file, incremental backup copies only those files 
physical portion of the total storage area of one or more which have been updated since die previous secondary 
peripheral storage devices is referred to as a H storage copy was generated. Note that transferring a file by 
space 9 *. * migration may include the maintenance of a primary 

A typical data processing system includes both main 55 copy of a file in level 0 storage. The primary copy is, 
memory and one or more peripheral storage devices. A however, an empty file— the data in the file having been 
data processing system having a plurality of peripheral transferred to the secondary copy of the file in level 1 
storage devices arranged hierarchically is referred to as storage. 

a "data storage hierarchy**. In a data storage hierarchy, Storage management is traditionally performed man- 
primary or level 0 data storage generally refers to the 60 ually. The data owner decides when to migrate or 
level therein having the highest performance and low- backup data, and where such migrated and backup files 
est storage capacity. should be stored. Such decisions are time consuming, 

Secondary or level 1 (or lower level) storage includes usually requiring a review of each file stored. The oper- 
the (equal or) greater storage capacity, but at (equal or) ations involved are often so time intensive that manual 
reduced performance and thus reduced cost The unit of 65 reviews and decisions are not made until there is no 
data storage can be data sets, files, or objects. Data set alternative. For example, a user might not migrate any 
. and file are terms used essentially interchangeably in files to level 1 storage until all storage space in level 0 
different operating system environments to mean a col- storage is in use. In large systems, or in any system 
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storing relatively large amounts of data, h is simply and time a file was last accessed (whether the file was 
mipracttcal to perform storage management manually. updated or not), and the date and time of last backup 

In recent years, computer software has become avail- and update of the file, 
able which reduces the need for manual operations. The One or more common DASD include one or more 
IBM Data Facility Hierarchical Storage Manager 5 control files for storing control information also needed 
(DFHSM) application program is an example of such for storage management These control files are not 
software. DFHSM is a utflity to the IBM Multiple Vir- themselves managed by DFSMS, but may co-exist on 
tual Storage (MVS) series of operating systems. common DASD with managed data files. A separate 
DFHSM uses specified management criteria to manage control file exists for each type of storage management 
files, including the automatic recall of a transferred file 10 activity (Le. one control file for migration, one control 
upon an attempt to reference the file by a user. The file for backup, etc.). For example, a control file in- 
management criteria include the minimum length of chides the information necessary to map migrated and 
tome a file win be permitted to be resident in the data secondary copies of files to their catalog and table of 
storage hierarchy or a particular level thereof before it contents entries, and/or their primary copies (Le. to 
wfll be eligible to be migrated or deleted or the maxi- 15 their level 0 source files). Such mapping allows for 
mnmlengA of time a file wfll be permitted to exist recall of the correct migrated or secondary copy of a 
without being backed up after being updated. Numer- file upon specification of such file by a user. After deter-" 
ous management criteria are defined to the system and mining that the primary copy of a file has been mi- 
stored in a configuration file. The DFHSM manage* grated, or that the secondary copy is required, the map- 
merit criteria are selected manually at the time of file 20 ping data is used to locate and access the migrated or 
identification to DFHSM. While DFHSM improves secondary copy of the file. 

storage management, the manual selection of manage- Actual storage management by DFSMS occurs dur- 
ment criteria is still burdening. mg periods of relative system inactivity to minimize 

In recent years, manual operations for storage man- interference with other processing. During the pre- 
agement have been further reduced. System-managed 25 scribed periods, DFHSM is called to compare the man- 
storage is a term indicating that the system itself selects agement attributes of files to the management criteria of 
the management criteria for data and performs storage such files, as defined by the assigned management class, 
management The storage adimmstrator need only de- DFHSM then manages the files accordingly, transfer- 
fine the management criteria m a configuration file, the ring files and updating the management attributes and 
system itself selects the management criteria for a par- 30 control information as required. In addition, storage 
tocular file upon its creation arid manages h accordingly. management may be applied to units of data larger than 
An example of software providing system-managed a file. For example, a group of files having certain com- 
storage is IBM Data Facility Storage Managemen t Sub- mon management requirements may be established such 
SS^e^^ 6 ' . hcrcmaftcr referred to simply as that the entire group is managed as a whole. The group 
™2wo r >FSMS B a trademark of IBM Corporation). 35 is assigned a management class of its own and managed 
DFSMS is a subsystem of the IBM Multiple Virtual accordingly. It should be understood that where files 
Storage (MVS) series of operating systems. DFSMS are hereinafter described as being managed during stor- 
S^Pf 5 " Jf^, . ™*^P™x*K> nicroding age management, entire groups or other data units 
DFHSM and IBM Multiple Virtual Storage/Data Fa- could be similarly managed, unless otherwise specified. 

^£^2 5f^ Wa 5Hr^f emafter referred to ampty «° Another example of computer software to provide 
asMVS^FP(MVS^FPBatradeinarkof IBM Cor- system-managed storage is IBM Data Facility Storage 
^^Se *^ t. * Management Subsystem for Virtual Machines software 

DFSMS ! accomplishes the aforementioned with the (hereinafter referred to simply as DFSMS/VM1 which 
j£™ ^ tomatic selection (ACS) routine is a subcomponent of the IBM Virtual Machine (VM) 
to MVS/DFP. The management criteria are defined in 45 series of operating systems. The currently available 
sets of such crrtera (known by names such as storage release 1 of DFSMS/VM does not provide space or 
and management classes, but hereinafter referred to availability management, but does provide severalim- 
smiply as ^naimgement classes") in a configuration file provements to the VM operating systems. Tradition- 
and^ACSroutnien^isdefiiiedonceby the storage ally, VM operating systems have used a minidisk file 
t^^wwc^^ 55 ^ *f ^ m * h to » system (MFS) for organizing data for users on periph- 

DFSMS, MVS/DFP uses the ACS routine to automati- eral storage devices. MFS preallocates contiguouTstor- 
caHy select the management class therefor. ACS selects age space (a consecutively addressed logics portion of 
fteinaMgem^t class based upc^ certam characteristics a physical storage space) within the dam storaw hierar- 
of a ffle, such as the name of the file, the owner of the chy to individual users. Each preallocated contiguous 
BJMhe ^directory path to the file, and the size of the file. 55 storage space is known as a *%iinidisk" because it ap- 
Once the ACS routine has selected the management pears to be a complete peripheral storage device (such 
C ^ kSS rL? such management class is stored in one or as a DASD) to the user. A minidisk is a set of consecu- 
m ^^wo m a Catalog cxistin S ™ the host processor. tively addressed DASD cylinders. Each minidisk is 
DFSMS must also provide for storage of the current owned by (Le. assigned to) a particular user, no other 
data management attributes associated with each file. 60 users can store or access files thereon unless so autho- 
The management attributes are stored in one or more rized by the owning user. A minidisk (and MFS) is said 
fields in the catalog, and/or the volume table of con- to be "preallocated" because the storage space reserved 
tents for each volume of data. The management attri- to a user is typically larger than that immediately 
butes mcJude certain data relating to the status and use needed by that user. As a user fills a minidisk with filel 
of each file and are updated as such data changes during 65 there is a tendency to try to keep at least a portion of 
use. For example, the management attributes include that minidisk available for new files by manually delet- 
the date and time a file became resident in the data ing the existing, unused files. The condition of "under- 
storage hierarchy or a particular level thereof, the date utilization" refers to the remaining increments of un- 
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used storage space spread throughout the data storage „. . . „„ — ~— 

li^^nd^^dpi^^a^orw^ SUMMARY OF THE INVENTION 

storage space. In addition, "fragmentation** results In view of the foregoing, it is the principal object of 

when a mtniHfcV is deallocated from a particular user the invention to improve storage management of file 

and cannot be reallocated to another user because it is 5 systems. 

too small to meet the needs of such other user. Another object of the invention is the storage man- 

A relatively new file system, known as the "shared** agement of a file system in which the catalog is too full 

file system (SFS), is mchidrd in current releases of VM *> accommodate the storage of both the management 

operating systems, such as Virtual Machine/System classes and m a n ag ement attributes reamed for storage 

Product (VM/^ released Shared 10 management. ... 

candy reduce undenmlization and fragmentation prob- another object of the invention is die storage 

tens as compared to MFS. However, because of the management of both MFS and SFS files in a single 

large number of existing VM operating systems users, virtual machine operating system environment 

the use of MPS has not been discontinued. Thus, SFS 9m ^J?*? ^i**** 1 * accornplished by using a 

and MFS may exist smiuhaneously in a data storage 15 S^l^^™^^^^^ 

hierarchy. SFS allows for the dyiiamic sharing of pes !*P°? t0ry 2* s P^X° r ca ^^ t ^ 

rinturai7trL. n a.p .■ m.uj L .n jiinw in pk^^i toiy ts created m die repository SFS file space for each 

storage space is not J^ocuh5d to u user account &ectQT ^ m ^ repository SFS file space causes the 
I«istea4ase^u»ac^ 20 ACS routine to a^dcafly select thTmanagement 

b dynamicafly allocated for tha file only Users are ^ for sochGlc and/or directory and store^mdica- 
f^^nT Pool, wtoch is simply a collec- ^ m ^ ^ ^ ^ doneforany 

tionof filesfor asetd^s. In .^operatmg systems, SFS file or directory. A naming convention is used to 
a file pool is a collection of imnidisks owned by a smgle hnkcach file and/or directory in the repository SFS file 
virtual machine that contain files for a number of users. M space with its associated MFS file and/or minidisk. The 
Each user stores files in a logical file space whhin a SFS additional SFS files are left empty as no other informa- 
storage group, which is a collection of minidisks within tion need be stored for storage management purposes, 
a file pooL The storage space assigned to a file space DFSMS/VM compares the management attributes of 
changes dynamically as files are added thereto, deleted the files to the management criteria represented by the 
therefrom, or updated. The files in each file space can 30 management classes in the SFS catalog and manages the 
be organized into one or more directories (and subdirec- MFS files accordingly. 

tones within each directory), the file space itself being a The foregoing and other objects, features, and ad van- 
top level of the directory hierarchy. tages of the invention will be apparent from the follow- 
SFS includes control information in level 0 storage as ing more particular description of the preferred embodi- 
. part of every file pool The control information includes 35 ment of trje invention, as illustrated in the accompany- 
files of information used to locate minidisks in the re* ing drawing. 

^^?J?tt£f£Z££l BRIEF DESCRIPTION OF THE DRAWING 

includes a catalog of information about the directories FIG. 1 is a schematic block diagram of a data storage 
and files in the file pool, such as the owner of each file. 40 hierarchy according to the invention. 
Multiple, file pools can exist for each instance of FIG. 2 is a schematic block diagram of a series of 
DFSMS/VM, each file pool being an instance of SFS. operating system environments according to the inven- 

If DFSMS/VM is to provide storage management ^ arranged in a network, 
for both MFS rmnidisks and SFS file pools (and the files FIG. 3 is a schematic block diagram of an operating 
of each), it must be able to store both the assigned man- 45 system environment in the data storage hierarchy and 
agement class and management attributes for each file network of FIGS. 1 and 2 according to the invention, 
or group of commonly managed files therein. This is FIG. 4 is a flow diagram of the operations for defin- 
relatively simple for SFS files because the SFS catalog mg a file to the storage management subsystem accord- 
has been designed with enough remaining storage space „ in^tte mvention. 

to accommodate storage of the ir^gement chis^md 50 » % <hi fT °* mana g emcnt 
management attributes for each file or group of com- operations according to the invention, 
monly managed files, A previously unrecognized prob- . DETAILED DESCRIPTION OF THE 
km is that of how to accommodate the storage of both PREFERRED EMBODIMENT 
m a na ge men t classes and management attributes for „ Bo f - ft „^ ^^^,in^« *k- a~>»~ 

MR files. The first cylinder of^ach MFS rninidisk is 55 Refer /^« «"* ^^V? ^ *» B * ia « 
IT V , ^ >r ^ numerals denote like features and structural dements in 
usedto store the catalog ofmfonnaUon for the user files ^ ^ fi ^ mvcnt ion wfll be described as 
storedm t^rernammg files. No space remains m the practiced in a network of multi-host processor data 
allotted MFS catalog cylinder to accornmodate the processing environments each having a plurality of 
storage of both the management classes and the man- w peripheral data storage devices. It should be understood 
agement attributes. One solution to this problem is to that the invention may also be practiced in a variety of 
increase the number of cylinders allotted for the cata- data processing system structures, such as those having 
log. Such enlargement of the catalog would result in a smaller number of peripheral data storage devices, 
restracturing and reprogramming of VM operating different types of peripheral data storage devices, or 
systems and would have severe impact to existing appli- 65 single host processor environments, 
cations expecting the precise current location of the Referring to FIG. 1, a data storage hierarchy 12 in a 
catalog. Thus, a different solution to the problem is multi-host processor environment will now be de- 
required, scribed. The system includes two or more host proces* 
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sors, such as a host processor 10a and a host processor nurnications for VM (APPC/VM) protocol is used. 
106, each including the usual component portions of a Further description of the network structure can be 
host processor, such as the arithmetic logic unit, control found in IBM Manual SC24-5378-00, VIRTUAL MA- 
unit, etc. Each host processor can be a uniprocessor ox CHINE/SYSTEM PRODUCT CONNECTIVITY 
multiprocessor. An example of a host processor which S PLANNING, ADMINISTRATION AND OPERA- 
may be used in the data pr ocess in g system shown is the TION RELEASE 6 and IBM Manual SC24-5377-0Q, 
IBM 3090 mamframe computer. Each host processor VIRTUAL MACHINE/SYSTEM PRODUCT CON- 
may employ one or more operating systems to supervise NECTT VITY PROGRAMMING GUIDE AND 
the operations thereof In the preferred embodiment, REFERENCE RELEASE 6 which are available from 
the host processors are uniprocessors using an IBM VM 10 IBM Corporation and which are hereby incorporated 
operating system. by reference. 

Host processors 10a and 106 are coupled to relatively Each VM operating system 35 of TSAF collection 33 
high and relatively low performance D ASD for storing (two are shown for each TSAF collection 33) includes 
relatively active and relatively inactive data, respeo- DFSMS/VM. The VM operating system including the 
tively. High performance DASD 14 are part of level 0 15 DFSMS/VM application is provided to a host proces- 
(**L0") of data storage hierarchy 12. Level 0 is the high- sor on a data storage medium and uploaded to ™in 
. est level of, the hierarchy. Low performance DASD 15 — memory as required. Within each VM operating system 
are part of level 1 C*L1**) of data storage hierarchy 12. 35 is one or more SFS file pools 36 (and SFS storage 
Level 1 is the next highest level (or at least, some rda- groups within a file pool) and/or one or more MFS 
tively lower level) of the hierarchy. An example of a 20 minidisks (not shown). A file pool (or storage group) 37 
DASD which may be used in data storage hierarchy 12 is part of one of the VM operating systems and includes 
is the IBM 3380 or IBM 3390 DASD. High perfor- a file space owned by DFSMS/VM (Le. assigned to the 
mance DASD 14 could be IBM 3390 DASD and low user id that is DFSMS/VM). Users of network 30 could 
performance DASD 15 could be IBM 3380 DASD, or also be assigned file spaces in file pool 37. The use of the 
high performance DASD 14 could be cached and low 25 file space owned by DFSMS/VM is shared among all 
performance DASD 15 could be without cache, etc. VM operating systems 35 in network 30. Additional file 
Each DASD stores a volume of data. Hierarchy 12 spaces owned by DFSMS/VM may be created, such as 
could also include additional storage levels, or different one file space for each type of storage management, or 
types of peripheral storage devices, such as tape drives. a single integrated file space may be used. Also, if a 
Note that level 0 storage and level 1 storage could sim- 30 single file space owned by DFSMS/VM is used, a di- 
ply be logical partitions of the same performance pe- rectory could be created within the file space for each 
ripheral storage device. Thus, in some mbodiments, it type of storage management, or a single integrated di- 
is possible to have a single peripheral storage device rectory may be used. 

shared among both level 0 and level 1 storage. Referring to FIG. 3, an individual IBM VM operat- 

The remaining components of the data processing 33 tng system environment employing DFSMS/VM ac- 
system, such as the system console(sX are not shown in cording to the invention wfll now be described. One or 
the drawing. The dotted and dashed lines represent more user terminals 20 interact with a host processor 
possible additional system components. Additional host naming the operating system through input/output 
processors and peripheral storage devices, including terminals. The terminals are coupled to one or more 
other types of peripheral storage devices, could be 40 host processors 10 running the IBM VM operating 
added as required. The ability to add system compo- system which is in turn coupled to peripheral storage 
nents is limited only by the connectivity of the compo- devices to create a data storage hierarchy 12. The VM 
nents. The re mainin g and additional data processing operating system includes two basic components shown 
system components, and details of the connections be- in the drawing, the control program (CP) 21 and the 
tween the components, are not shown in the drawing, 45 conversational monitor system (CMS) 22. 
but are well known. CP 21 manages the processor environment to make it 

Referring to FIG. 2, a series of VM operating sys- appear to each user that he is in an independent and 
terns, each running DFSMS/VM, is shown arranged in fully functional processor environment These virtual 
a network 30. A network is a set of two or more com- machines appear to operate independently and shnnlta- 
puter systems linked in such a way as to let data to be 50 neously. CP 21 also monitors and managf* system re- 
transmhted. between them. Here, network 30 is de- sources, controls the recovery from hardware prob- 
signed according to the IBM Systems Network Archi- lems, and accounts for system usage. Usually, a user 
tecture (SNA). Network 30 is divided into a series of requires some other operating system to actually do 
subnetworks 31 (two are shown) coupled by gateways useful work, such as CMS 22. 

32. Each subnetwork 31 includes one or more transpar- 55 The VM operating system supports its own interao 
ent services access facility (TSAF) collections 33 (four tive component, CMS 22, which is actually an operat- 
are shown) each coupled by one or more gateways 34. ing system that runs only on a virtual m^Nnc CMS 22 
TSAF is a component of a VM operating system that provides for two-way conversation between users and 
handles communications with other operating systems the system— allowing users to develop and execute 
by proper routing of the communications. A TSAF 60 application progr am s, communicate with other users, 
collection is a group of up to eight interconnected VM and create and edit files. CMS 22 includes two known 
operating systems. A gateway is a uniquely named logi- file systems to create and edit files, MFS and SFS 23 
cal unit for a subnetwork 31 or TSAF collection 33 used including file servers therefor), as previously de- 
fer communications therebetween. Gateways 32 and 34 scribed. MFS is represented by the coupling of users 20 
are c ommunica tion servers including a logical proces- 65 to level 0 DASD 14a and 146. DASD 14a is a CMS 
sor which provides the protocol for communications minidisk and DASD 146 is a non-CMS minidkk used 
between subnetworks 31 and TSAF collections 33. for level 0 storage. SFS 23 is coupled to level 0 DASD 
Here, the IBM Advanced Program-to-Program Com- 14c and level 1 DASD 15 and includes SFS catalog 29. 
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A single instance of SFS is shown in the drawing (Le. Storage management of the files in data storage hier- 
one file pool), but a plurality of such could be included. archy 12 re qui res the storage of management criteria 
CMS 22 also supports other programs for various apph- and management attributes. The management criteria 

Cations. Further description of these Components Of the are defined as Tnanngi rpen t rlftgcps m ft rafrnfignratirm fflf 

VM operating system may be found in IBM Manual 5 as part of the control information. SFS catalog 29 stores 
SC24-528441, VIRTUAL MACHINE/SYSTEM the management classes selected by ACS routine 25 for 
PRODUCT APPLICATION DEVELOPMENT each SFS file. SFS catalog 29 also stores the manage- 
REFERENCE FOR CMS RELEASE 6; IBM Manua l meat attributes for each SFS file. Storage management 
SC24-5367-00, VIRTUAL MACHINE/SYSTEM of the SFS files includes the usual comparison of the 
PRODUCT CMS SHARED FILE SYSTEM AD- 10 management criteria represented by the management 
MINISTRATION RELEASE 6; IB M Man ual SC24- classes to the management attributes, and any actions 
5369-O0, VIRTUAL MACHINE/SYSTEM PROD- required thereby. Each level 0 storage space 26 of a 
UCT USING RELEASE 6 ENHANCEMENTS RE- SFS file space may include one or more directories and 
LEASE 6; all of which are available from IBM Corpo- subdirectories. These logical groupings of files may 
ration and are hereby incorporated by reference. IS simflarry be assigned a management class and managed 

Another component of the VM/SP operating system by DFSMS/VM 24. Further description of these data 
shown mtte stiuct ui es can be found in .the aforementioned, docu- 

but mortifie d to be a centralized and system-managed ments incorporated by reference, 
storage management facility. According to the iriven- To accommodate die storage of both the manage- 
turn, DFSMS/VM may include both space and avail- 20 ment class and management attributes for MFS files and 
ability management In different embodiments, both minidisks, a single repository SFS file space having 
availability and space management are provided for level 0 storage space 27 on DASD 14c is created. The 
MFS files and SFS files, availability m a nageme nt is repository file space can be located in file pool 37 and is 
provided for both MFS files and SFS files and space owned by DFSMS/VM 24. For each MFS file identi- 
management is provided only for SFS files or vice- 25 fi^j to DFSMS/VM 24, an empty file is created in the 
versa, or either availability management or space man- repository file space. For each such MFS minidisk, a 
agement oriy is r^vided for both MFS and SFS files. directory is created in the level 0 portion 27 of the 
In the embodmient de^l>edhere t availability manage- repository file space. The creation of each empty file or 
ment is provided for both MFS fifa and I SFS I files and directory in the level 0 portion 27 of repository file 
spacemanagement * J^^^V/^^ «^ 30 space causes ACS routine 25 to automatically select a 

^^Z 0 ^^* 05 " 1 m DFSMS/VM 24 as it ism maDa&:mait class for such file or directory and store an 
^F^AW^^protocol ^oused to c^umca- indication of such in SFS catalog 29 as would be done 
tions between SFS23 and DFSMS/VM 2V and for for ^ S FS file or directory. The SFS files associated 

^ ^Lf"^ 23 ^ with the MFS files are left empty as no other mforma- 
DFSMS/VM 24. T^rem^g mto^ tesic oper- 35 tion ^ ^ for y stm ^ management 

SSImS^-^J^ ^^f^ °? f DFSMS/VM 24 compares the rnarTgernenT^ributes 
DFSMS/VH, except as ^^f^^^^ stored in the MFS catalog (not shown for convenience) 
those of existing releases of DFSMS or DFSMS/VM. ^ ^ manaKement cr ^ & represented bv the man 
inf0 ^^ 011 bo^FSMSA^M k imple- ^ ™ ^™ catalog 2JUnd manage the MFS 

men ted can be found m supporting documentation such 40 2?„ „. _ ; _sj;,.|_ „„,.•„,„ V, , . „ . 

as IBM Manual 002*4^^ DFSMS/VM GEN- ffles ™ d immdiste BOK«iii^y. Thus, forage manage- 

ERAL INFORMATION RELEASE 1; IBM Manual ^ aJ^X^^^LT^^l^ 
SC26-460M0. DFSMS/VM USER'S GUIDE; IBM ^J^ £^L ""^ mana « eBent of 

Manual LY27-958J-00, DFSMS/VM DIAGNOSIS A wo me sysiem. 

AGE, reprinted from IBM Systems Journal VoL 28, M m mUDed foUows: 

No. I, pp.77-103, 1989; IBM Manual GG24-3403-00, Eepooad^FSMSixiMlNIDlSKMAPi 

DFSMS IMPLEMENTATION PRIMER SERIES: SO 

WRITING ACS ROUTINES; IBM Manual SC26- 

4514-01, MVS/ESA STORAGE ADMINISTRA- where: 

TION REFERENCE VERSION 3 RELEASE 1; M filepoolid M is the file pool name. 
IBM Manual GC26-4507-01, MVS/ESA DATA FA- "DFSMSxxx" is the file space name. This name form 
CILITY PRODUCT GENERAL INFORMATION 55 signals DFSMS/VM 24 that the repository file space is 
VERSION 3; IBM Manual SH35-0083-04, DATA FA- to be managed by DFSMS/VM, but that files therein 
CILITY HIERARCHICAL STORAGE MA NAGER are not themselves to be migrnt-H 
SYSTEM PROGRAMMER COMMANDS REFER- "MINIDISKMAP" is a constant name which clearly 
ENCE VERSION 2 RELEASE 5. AH of the afore- distinguishes a repository file space for availability man- 
mentioned documents are available from IBM Corpora- 60 agement from a repository file space for other storage 
tion and are hereby incorporated by reference. Further management functions (such as space management), 
information is available in U.S. Pat Nos. 4,638,424, Note that a single repository file space could be used for 
4,77 1,375* and 4,876,662, which are also hereby incor- all storage levels. 

porated by reference. User terminals 20, SFS 23 and "fqluname" is the combined (concatenated) name of 
DFSMS/VM 24 are implemented as virtual machines 65 subnetwork 31 and gateway 34. This uniquely identifies 
under CP 21. CMS 22 is actually incorporated into the TSAF collection 33 that the minidisks being man- 
these virtual machines, but is shown separately to den> aged reside in and is obtained from parameters specified 
onstrate its function. by the storage administrator of DFSMS/VM 24. 
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"smsglobresuT is the TSAF collection-wide naming convention would use * 4 mdowncr r * and "vaddr" 
APPC/VM resource name for the VM operating sys- instead of "fitepool" and "storagegroup" to uniquely 
tern 35 and DFSMS/VM 24 which is managing the identify the level 1 MFS files. 

minidisks, uniquely identifying such within a TSAF By inherently guaranteeing the uniqueness of a SFS 
collection 33. This also is obtained from the control file 5 file 

T ifttn^ across network 30 in the naming schynr itself, 
of DFSMS/VM 24. the need for control files similar to those used in 

"mdowner" is the user name of the owner of the DFSMS for mapping migrated files to their primary 
rninidisk being managed. copy & chrnfnatrd, If the naming scheme is similarly 

**vaddr** is the virtual address of the minidisk being gsed f or common level 1 storage for other types of 

managed - 10 gtnrny mftnagw rwrrt In ftHrtttirm tn ftpftf^ manag ement, a 

To access a file, the file name and file type are also single file space can be used for level 1 storage for each 

required. The files within the directories of the reposi- ^ ^ stQ[3 ^ management, or a separate file space 

S^iSSKS* ^ VC ^ ^ ^^f 1 ffl ' typCS 85 may be used for level 1 storage for each space manage- 

^^^^^^J^"^^^^ ment function. If the iiammg scheine b smnlariy 

can ibe placed jnrtsown SFS storage group to mmmirze \$ fa common level 1 storage in availability management, 

^TtZ ^J^^^L^^^l^L whb control files for mapping may not be entirely elhm- 

The same naming scheme is used m conjunction with- - u^r^. ZZ2L^!L u'J&rz^AZZ* t» " 
a SFS internal identifier to allow level 1 storage to be T^TT* J®!a^^ 

shared across network 30 for sr^ manager^ V™™* «W of a file to the se«mdary copies of a file, 

pool 37 includes a file space, which may be the reposi- 20 METHOD OF OPERATION 

tory file space, having some common level 1 storage , . ' mM| , - ,*^ mo a H{JtQ 

space 28 therein. Storage space 28 is thus used to store . ^JJgJ?. the method of definmg a date 

all of the migrated SFS files for network 30, regardless enutyto DFSMSmi according to the mventoon wffl 
of their owner and source location. The naming scheme now described. Operations begin at step 100 or step 
is used to inherently and uniquely identify a migrated 25 105 "P 011 ^ of trie host processor, depending upon 
SFS file or directory, regardless of the file pool 36, whether the data entity is a SFS file or directory, or a 
operating system 35, TSAF collection 33, and subnet- MPS file or minidisk respectively. For a SFS file or 
work 31 from winch the SFS file was migrated. The directory to be managed by DFSMS/VM, such file or 
directories are named as follows: directory is created at step 115. At step 120, the ACS 

routine assigns the management class to the file or direc- 
fDcpool^lJ^I^Sxxx.MIGRATIO^a-EVELlf■ tory, which is stored in the SFS catalog. The flow then 

qtmwnf gmgiobfrridfiTrpooi ttora^ ^ returns at step 125. For a MFS file or minidisk, such file 

or minidisk is created at step 110. Then, at step 115, an 

W 7 c t rc: „ „. «r^~»*o y% 4*r , *% • empty SFS file is created in the repository file space 

•vZSrSd- are^vSv de^T ' 35 corresponding to tr* ^ ^ 

^SS£^t storage group fro^ wmch the ^S^^^orage management opera 
To locate a nutated SFS file, the file name and file 40 Uons ^ pFSMS^^ccordmg to the mvention will 
typearealsorequire^^ ™» * DFSMS/VM is called by the host 

Iwvea file name and a file type whi^ Jlf^L^e^f^ - ^f^^ ™ : . At J*fP 

SFS internal identifier for thTasscxaated level 0 source 135 * D ^ MS <>^ 1 exaimBe l^ first data 
file. SFS 23 uses the internal identifier in existing re- managed, as hsted m the SFS catalog and/or MFS 
leases of VM operating systems to uniquely identify a 45 catalog. Step 140 branches "wording to whether the 
file within a file pool 36. This is required because multi- first such item in the list is a SFS file (or cnrectoryX or 
pie users have access to the same file pool and may thus a MFS file (or minidisk). If the first data entity is a MFS 
each place a file therein having the same file name and file or minidisk, DFSMS/VM compares the manage- 
file type. The SFS internal identifier allows SFS 23 to 10011 criteria represented by the management class in 
differentiate between such otherwise commonly named 50 SFS catalog to the management attributes of the 
files. In the preferred embodiment, the naming scheme m the MFS catalog at step 145. If the first data 

uses an eight EBCDIC character file name and an eight entity is a SFS file or directory, DFSMS/VM compares 
EBCDIC rhnrm+r file type The SFS internal idennV the management criteria represented by the manage- 
fier is translated from 8 characters of binary data (as ment class in the SFS catalog to the management attri- 
used within SFS 23) into 16 EBCDIC characters repre- 55 butes of the data m the SFS catalog at step 150. If no 
senting hex code, one hex code character per each half management action is required, step 155 branches to 
byte of binary data, for use in the directory of storage step 175. If any action is required, such as a data migra- 
space 28. tion, backup, or deletion, such action is taken at step 

In the described manner, each SFS source file or 160. Such action includes the use of the naming scheme 
directory in network 30 is uniquely identifiable in the 60 to inherently and uniquely identify a level 1 file across 
storage space 28 or a directory thereof. Storage space the network. The relevant subcomponents of the afore- 
28 can thus be used to store all of the level 1 SFS migra- mentioned naming scheme are acquired and concate- 
tion files for the entire network 30, thereby reducing the nated for use as required. Data transfers may be accom- 
overhead that is associated with maintaining file spaces panied by data compaction. Step 160 may also include 
and/or storage devices for level 1 storage of each file 65 updating the relevant directory entries to reflect any 
pool 36, VM operating system environment 35, TSAF change in the status of the data, such as an indication 
collection 33, etc. If in an alternative embodiment space that a file has been migrated or that a secondary copy of 
management is similarly provided for MFS files, the the file exists. At step 170, the management attributes in 



13 



5,317,728 



the SFS catalog (and, possibly, also the MFS catalog) 
are updated to reflect the action taken, Step 175 then 
branches according to whether there is another data 
entity that has not yet been wsmtnpH for storage man- 
agement If there is another data entity, the flow 
branches to step 180 to examine the next data entity and 
then returns to step 140l If there are no more files to 
exaimnfY DFSMS/VM returns control to the host pro- 
cessor at step 185. 

Pseudocode listings according to the invention are 
provided below. The first listing is for defining MFS 
files and minidisks to DFSMS/VM and for the selection 
of management classes therefor. 
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While the invention has been shown and described 
with reference to a preferred embodiment thereof, it 
wiD be understood by those skilled in the art that vari- 
ous changes in form and detail may be made therein 
without departing from the spirit, scope and teaching of 
the invention- For example, in FIG. 2, the number of 
networks, TSAF collections, VM systems, file pools . . 
. could be varied. 

Accordingly, the invention disclosed herein is to be 
limited only as specified in the following claims. 

What is claimed is: 



/* System managed storage of ndnidisks using SFS as a */" 

/* repository to store management classes. */ 

/* This routine handles only the availability management */ 

/* of MFS files function. */ 

input: 

xnlnidiskj3ackup_repository_filepoolid char (8) # 
minidisk_backup_repository_f ilespace char ( 8 ) , 
fully_qualif iedJLuname char (16) , 

DFSMS_global_resource_id char ( 8 ) , 

#_of_minidisks fixed(31) , 

minidisk_list array ( #_of_minidisks) 

owner char (8), 

vir tual_addres s char ( 4 ) ; 

declare : 

minidiskJt>ackupjrepository_name constant ( 'M1N1DISKMAP ■ ) ; ' 
do i « 1 to #_of_minidisks; /* for each minidisk inputted */ 



/* build minidisk backup repository directory name by 
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/* concatenating input values 

inbr_dirname=^nidiskJbackup_repository_filepoolid 

minidiskJaa<tfcup_repository_filespace 

minidiskJbackup_repository_name 

fully_qualified_ luname 

DFSMS_global_resource_id 

minidisk_list(i) .owner 
" minidisk list (i) .virtual address; 



if (mbrjdirname directory does not exist) then 

create directory mbrjdimame using SFS DMSCRDIR CSL 
call; 

create listjof_f iles_to_be_managed from the CMS minidisk 
directory; 

create list of files in mbr_dirname using SFS DMSOPDIR and 
DMS6ETDI CSL calls; 

do j b 1 to #jof_f iles_on_minidisk; /* for each file on */ 

/* minidisk */ 



if (list_of_files_toJt>e_managed( j) has no corresponding 
file of the same filename and file type in mbrjdimame) 
then 

create an empty file of this filename and f iletype in 
mbr_dirname using SFS DMSOPEN CSL call; 



if (this is an unconditional backup) then 



5,317,728 

17 18 
call backup_f ile ( list_pf_f iles_to_be_managed ( j ) ) ; 

else do; /* Incremental backup */ 

call SMS_processing_ decision passing the management 

class of the file in mbrjdirname and the file's 

management attributes ; 
"if decision is BACKUP_FIL£_DECIS ION then 

call backup_f ile (listjof_f iles_to_be_managed ( j ) ) ; 

end; /* incremental backup do */ 

end; /* do for #_of_files_on_minidisk */ 

end; /* do for #_of_minidisks */ 

The second listing is for space management of SFS files and 
directories* "MC" means management class; "MLl" means level 
1 storage for migrated data. "Null" means that a set of 
blanks have been purposefully assigned as the management 
class for a file or directory. The listing first shows 
obtaining a null, non-existent, or otherwise (regularly) 
assigned management class for a file, with a default to 
obtaining a null, non-existent, or otherwise (regularly) 
assigned management class for a directory if the management 
class for a file is null. The listing then shows data 
expiration said migration decisions/actions based on the 
management class and management attributes. 
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/* Obtain MC definition and make initial decision based */ 



select on the File_Management_Class input parameter: 
when (null) then 

select on the Directory_Management_Class input 
parameter: 
when (null) then 
get the system default's management 

class/criteria 
if that management class does not exist in the 
current configuration then 

Output a no management class error message 
goto EXIT_POINT 
else if other error occurred, 

Output an internal error message 
goto EXITJPOINT 
when (no management class indicator) then 

if the command issued input parm is MIGRATE then 
if File_Record_Size input parm > 0 then 
Decision = MIGRATE 
Migrate_Age = 0 
endif 

else (command is MANAGE) 
Decision = NONACTION 
endif 
otherwise 

get the directory's management class/criteria 



/* on MC Name 



.* 
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If that management class does not exist in the 

current configuration then 

Output a no management class error message 

goto EXITJPOINT 

else if other error occurred. 

Output an internal error message 

goto EXITJPOINT 

endselect 



when (no management class indicator) then . 

if the command issued input parm is MIGRATE then 

. if File_Record_Size input parm > 0 then 

Decision = MIGRATE 

Migrate_Age = 0 

endif 

else (command is MANAGE) 
Decision » NONACTION 
endif 

otherwise 

get the file's management criteria 
if that management class does not exist in the 
current configuration then 

Output a no management class error message 
goto EXITJPOINT 
else if other error occurred. 

Output an internal error message 
goto EXITJPOINT 
endselect 
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if Decision = MIGRATE or NONACTION then 

goto EXIT_POINT 

Make expiration decision based on MC Definition . */ 

if the Command_Issued input parm is MANAGE and 
the Datejof jCreation input parm > 0 and 
the Date_of_Last_Reference input parm > 0 then 
do 

if both expire-after-day s-nonusage MC criteria 
and 

expire-after-date/days MC parameter are NOLIMIT 
then 
do 

file is not to be expired 

end 

else if expire-after-days-nonusage = NOLIMIT 
or expire-after-days-nonusage <= (current-date 

minus Date_ of_Last_Ref erence input parm) 

then 

/* the two previous conditions mean that the 
/* expire-after-days-nonusage is either inappli- 
/* cable (NOLIMIT) or fulfilled. In either 
/* case, the expire-after-day s-attribute must 
/* now be fulfilled to expire the file, 
do 

if expire-after-date/days specifies an 

absolute date that is <= current date 
or expire-after-date/days specifies a 
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number that is <= (current-date minus 



Date_bfjCreation input parm) 



or expire-after-date/days = NOLIMIT 



then 



file is to be expired 



else 



file is not to be expired 



endif 



end 



else 



do 

file is not to be expired 

end 
endif 

if file is to be expired then 

if the Expiration Disposition MC criteria = 
ENTIRE then 

Decision = EXPIRE _FILE_ENTIRE 
else 

Decision « EXPIRE_FILE_DATA_ONLY 
endif 
endif* 

end 
endif 

if Decision = EXPIRE_FILE_ENTIRE or E XP I RE_F I LEJD ATAjONL Y 
goto EXIT_POINT 
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/* Make migration decision based on the MC Definition */ 
/* for those files not eligible for expiration */ 

select on Command-or-Auto-Mi grate MC criteria 
when (NONE) 
do 

Decision = NONACTION 
end 
when (BOTH) 
do 

if the Coxnmand__Issued input pann is MIGRATE then 
do 

if File_Record_Length > 0 then 

Decision = MIGRATE 

Migrate_Age = 0 
endif 

end 

else (command is MANAGE) 
do 

if Date_of_Last_Reference input parm > 0 
and Primary-Day s-Non-Usage MC criteria <= 

days since Date_ofJLast_Reference 

input parm 
and Storage_Level input parm = PRIMARY 
then 
do 

if File_Record_Length > 0 then 
Decision = MIGRATE 
Migrate_Age » Current-Date xainus 
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endif 



end 



else 



Decision = NO ACTION 



end 



end 

end 

when (COMMAND) 
do 

if the Coxnmand__Issued input parm is MIGRATE then 
do 



if File_Record_Length > 0 then 
Decision = MIGRATE 
Migrate_Age » 0 
endif 
end 
else 

Decision » NO ACTION 



Output invalid MC parameter Error message 



end 



otherwise 



end 



The third listing is for the generation of file and 
directory names in creating and accessing data migrated to 
level 1 storage. 
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Translate 8 byte hex internal identifier (ZD) to 16 



half byte of the ID (hex) represents a hex value 
between 'O'x ana 'P'x. These numeric values are 
translated into their full byte EBCDIC characters 
•0 1 through 'F*. The resulting 16 EBCDIC characters 
will be the filename and f iletype of the owned 
storage file* 

Obtain f ilepool id and MLl owned storage from 
DFSMS/VM control file 

Obtain fully qualified lu name from DFSMS/VM control 
file 

Obtain resource id from DFSMS/VM control file 

Obtain the storage group from the first two bytes of 
the ID 

Obtain the f ilepool from the input parameter 

Construct the directory of the file in owned storage 
with the above information in the following format 



byte EBCDIC character filename and f iletype. Each 



Filepoolid : DFSMSxxx .MIGRATI0NLEVEL1 . f qluname . 
SMSglobresid. f ilepool. storagegroup 
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While the invention has been shown and described with 

reference to a preferred embodiment thereof, it will be 
understood by those skilled in the art that various changes 
in form and detail may be made therein without departing 
from the spirit, scope and teaching of the invention. For 
example, in Figure 2, the number of networks, TSAF collec- 
tions, VM systems, file pools • . . could be varied. 
Accordingly, the invention disclosed herein is to be limited 
only as specified in the following claims. 



What is claimed is: 

1. A data storage hierarchy comprising: 
peripheral level 0 storage including a first storage 

space having a plurality of files thereon organized 
according to a first file system and a second storage 
space having a plurality of files thereon organized 
according to a second file system, the first file sys- 
tem including a first catalog storing mformation 
associated with the files therein and the second file 
system including a second catalog storing informa- 
tion associated with the files therein, the first stor- 
age space including a repository file space having 
an empty file therein for each file organized ac- 
cording to the second file system and on the second 
storage space, the first catalog storing first manage- 
ment mformation for storage management of the 
files organized according to the second file system 
and on the second storage space by means of the 
file entries in said repository file space; 
peripheral level 1 storage; 

a host processor coupled to the peripheral level 0 and 
peripheral level 1 storage; 

management means coupled to the host processor for 
moving and/or copying the files on the second 
storage space, between level 0 and level 1 storage 
to balance performance, storage, and cost, using 
the first management information; and 

a catalog of second management mformation for stor- 
age management of the files on the first storage 
space and management means coupled to the host 
processor for instructing the host processor to 
manage the files on the first storage space using the 
second management information. 

2. the data storage hierarchy of claim 1 wherein the 
first file system is shared filed system which dynami- 
cally allocates storage space, among a plurality of first 
file system users as their files are stored therein and the 
second file system is a preallocated file system which 
allocates contiguous storage space to each of a plurality 
of second file system users prior to their files being 
stored therein. 

3. A data storage hierarchy comprising: 
peripheral level 0 storage including a first storage 



space having a plurality of files thereon organized 
according to a first file system and a second storage 
space having a plurality of files thereon organized 
according to a second file system, the first file sys- 
tem including a first catalog storing mformation 
associated with the files therein and the second file 
system including a second catalog storing informa- 
. tion associated with the files therein, the first stor- 
age space including a repository file space having 
an empty file therein for each of the files organized 
according to the second file system and on the 
second storage space, the first catalog storing first 
management information for storage management 
of the files organized according to the second file 
system by means of the file entries in said reposi- 
tory file space and on the second storage space and 
second management information for storage man- 
agement of the files organized according to the first 
file system and on the first storage space, the sec- 
ond catalog not able to store the first management 
information; 

peripheral level 1 storage; 

a host processor to the level 0 and level 1 storage; 

management means coupled to the host processor for 
moving and/or copying the files on the second 
storage space, between level 0 and level 1 storage 
to balance performance, storage, and cost, using 
the first management mformation; and 

management means coupled to the host processor for 
moving and/or copying the filed on the first stor- 
age space, between level 0 and level 1 storage for 
the purpose of balancing performance, storage, and 
cost, using the second management mformation. 

4. The data storage hierarchy of claim 3 wherein the 
first file system is a shared file system which dynami- 
cally allocates storage space among a plurality of first 
file system users as their files are stored therein and the 
second file system is a preallocated file system which 
allocates contiguous storage space to each of a plurality 
of second file system users prior to their files being 

. stored therein. 

5. A method for the storage management of data in a 




data storage hierarchy, the data storage hierarchy in- 
cluding at least one level 0 peripheral storage device 
having a first storage space having a plurality of files 
thereon organized according to a first file system and a 
second storage space having a plurality of files thereon 
organized according to a second file system, the first file 
system including a first catalog storing information 
assoriatfd with the files therein and the second file 
system including a second catalog storing information 
associated with the files therein, at least one level 1 
storage device, and a host processor coupled to the 
level 0 and level 1 peripheral storage devices, the 
method comprising the inachme-executed steps of: 

creating an empty file on the first storage space for 
each file on the second storage space; 

in r e sponse thereto, assigning a management class to 




each file on the second storage space and storing 
such in the first catalog; 

assigning a managem ent class to creh file on the first 
storage space and storing such in the catalog of the 
first file system; and, 

moving and/or copying files on the first storage 
space, between level 0 and level 1 storage to bal- 
ance performance, storage, and cost, according to 
their management classes stored in the catalog of 
the first file system; 

moving and/or copying the files on the second stor- 
age space, between level 0 and level 1 storage for 
the purpose of balancing performance, storage and 
cost, according to their management classes associ- 
ated with said empty files stored in the first catalog. 
* * • * * 



